OPC Studio User's Guide and Reference
Generalized Controls and Dialogs
OPC Data Client consists of a large number of various objects, and many of them require viewing or editing by the end user - depending on the application. UI controls provide the means for the user to inspect value of these objects and modify their contents.
Some controls are quite specialized. For example, browsing for OPC data has many features and provides many interaction capabilities that are tailored just to the OPC browsing. Such controls are very flexible, because the developer needs a high level of control over their behavior, depending on the application he/she is developing. In case of the OPC browsing, the developer may need to customize the types of nodes that are displayed, where the browsing starts, the allowed depth of browsing into deeper levels, and so on. Similarly, displaying live data can be done in many ways, and a control that does that should allow the developer all necessary customizations as well.
On the other hand, there are many objects that are, in this sense, more "boring". In many cases, these may be configuration objects, for some parameters used in OPC. Controls for such objects typically consist of set of standard controls such as text boxes, combo boxes, radio buttons and so on, and there isn't much (if anything) that makes sense to be changed by the developer. Such objects, in total, clearly outnumber the objects that need a specialized control for their UI.
OPC Data Client could provide separate UI control for each supported editable or viewable object, but the number of such controls would soon grow rapidly, without much benefit to the developer. In order to overcome this problem, OPC Data Client has solutions that allow you to make use of editing and viewing capabilities for large number of object types, without resorting to bother you with separate UI control for each of them.
The automatic value control, represented by the AutomaticValueControl Class, is a single Windows Forms control that can be used for viewing or editing many OPC Data Client objects. Which objects precisely can be used in the automatic value control is document in "groups" in relevant parts of the specification. For example, the list of objects that can be used with automatic value control in OPC UA PubSub is here: OPC UA PubSub Control Pages.
When you initially place an empty automatic value control on your form, it does not show anything useful. In order to make it work, you need to configure its EditTypeName Property, and set it to name of the type you want to view or edit in the control. In most cases, this needs to be the assembly-qualified name of the type (https://docs.microsoft.com/en-us/dotnet/api/system.type.assemblyqualifiedname ). Such name consists of a fully qualified name of the type (including its namespace), followed by a command, and a name of the assembly where the type resides. For example, for the UASubscribeDataSetArguments Class, the assembly-qualified name is "OpcLabs.EasyOpc.UA.PubSub.OperationModel.UASubscribeDataSetArguments, OpcLabs.EasyOpcUA".
After you have configured the edit type name, the automatic value control will show in itself the UI control for that type, if available. If there was a problem selecting the appropriate control, and error message appears in place of the control. You can inspect the details of the error in the SelectionException Property of the control, if needed.
For example, when you set the edit type name as hinted above, you will get a control that in runtime looks similar to this:
In your code that works with control:
There may be multiple different control pages available for an object. Each control page is identified by an integer Id; for ease of reference, the control page Ids are also referred to by symbolic names. The default control page (which you get if you do not differ from the initial configuration of the automatic value control) is named ViewOrEdit and has an Id equal to zero (0). As the name implies, this control page is dedicated to viewing or editing the object.
You can find the pre-defined control pages Ids and their symbolic names in the ControlPageIds Class.
If the object is relatively simple, it can usually be covered by a single ViewOrEdit control page. In such (common) case, the ViewOrEdit control page is the only explicitly defined control page for the object. There are, however, also large and complex objects, and a single control page covering all aspects of the object would be too confusing for the user to work with. In such cases, the object may have additional, or different, control pages, such as Basic, Advanced, and so on.
If you want a specific control page for the object on your form, use the RequestedPageId Property of the automatic value control to select it. For example, if, for the same edit type as in the previous example ("OpcLabs.EasyOpc.UA.PubSub.OperationModel.UASubscribeDataSetArguments, OpcLabs.EasyOpcUA" you also change the RequestedPageId Property to ControlPageIds.Communication, you will get a control that in runtime looks similar to this:
The Properties control page Id (numeric value 1000) displays a viewable or editable property grid for the object. This control page is not explicitly defined with any object, but is always available, for any object.
The Multi control page (numeric Id is -1) displays a combination of all available control pages for the object, in a tabbed control where each tab page contains one control page. This control page is not explicitly defined with any object, but is always available, for any object. For example, if, for the same edit type as in the previous example ("OpcLabs.EasyOpc.UA.PubSub.OperationModel.UASubscribeDataSetArguments, OpcLabs.EasyOpcUA" you also change the RequestedPageId Property to ControlPageIds.Multi, you will get a control that in runtime looks similar to this:
If you ask for the ViewOrEdit control page, but the object does not have that control page available, a tabbed control is displayed instead, containing tab pages for all object's available control page in the numeric Id range between 1 and 1000 (where 1000 is for Properties). This means that if some object are more complex are their viewing or editing consist of multiple control pages but not the ViewOrEdit control page, you do not have to be explicitly aware of that - asking for ViewOrEdit control page will always give you the most appropriate and usable control for the object. The fact that the numeric range end at 1000 means that some rarely used control pages (such as the Expert page) with higher Ids are not used in this case.
Your application has (sometimes implicit) requirements on the behavior of the UI controls it wants to use, and the UI controls that you obtain though automatic value control can differ in their behavior too. For example, your application may require a control that is read-only, or read-write.
Such traits of the automatic value control can be specified using dedicated properties on the AutomaticValueControl Class . They are:
| Name | Default Value | Description |
| RequestNullable Property | false |
Requests that the interactive user of the control can set the value to null. Note: You can always set the null value to the control from your code. Doing so effectively clears the information from the control and disables its relevant constituent controls. A control that has the Nullable trait, however, can be set to null (or non-null) by the user that is interacting with the control in runtime.. |
| RequestPolymorphic Property | false |
Requests that the interactive user of the control can change the type of the value. Note: Te Polymorphic trait only makes sense if there are subtypes of the edit type that you specify for the control. |
| RequestReadWrite Property | true | Requests that the interactive user of the control can change the value. |
A specific control page may react to one of these required traits by modifying its behavior accordingly, or, it may be unable to fulfill the request. For example, many control pages do not support the Nullable trait natively.
In case that the control page itself is not able to provide the requested trait, there is a logic contained in the automatic value control that attempts to provide the trait externally, usually by wrapping the control page in a special control that extends the control page by the required trait.
In the example we used, the ViewOrEdit control page of the type used "OpcLabs.EasyOpc.UA.PubSub.OperationModel.UASubscribeDataSetArguments, OpcLabs.EasyOpcUA" does not, by itself, allow the interactive user to set the value to null. But you can still set the RequestNullable Property to true, and the automatic value control will deal with it. It will add a "Specify explicitly" check box, giving this resulting control:
Here, when the check box is unchecked, the rest of the control is disabled, and the value is null. When the check box is checked, the value is non-null, and the rest of the control is enabled.
Similarly, the automatic value control can add polymorphism to a control page, using a drop-down box with available types. There is also a logic which detects when both Nullable and Polymorphic traits are requested, and such combination can be handled inside the drop-down choices, without an additional checkbox for "null". The automatic value control has even more rules and logic built into it, so that it provides meaningful and usable results whenever possible.
If the control page does not provide the specified combination of requested traits natively, and the automatic value control is also unable to provide the requested traits externally, the automatic value control goes into an error state, and displays a corresponding error message in place of the control page.